Unifying Web And Phone Presence

ABSTRACT

The subject matter of this specification can be embodied in, among other things, a computer-implemented method that includes obtaining, at a computer system, a plurality of contact identifiers for a computer account holder, wherein the identifiers represent a plurality of different communication modes; identifying a handle for the account holder, wherein the handle is associated with a uniform resource locator; and correlating the handle with the plurality of contact identifiers, and storing the handle and plurality of contact identifiers together so as to permit retrieval of the contact identifiers in response to identification of the handle.

TECHNICAL FIELD

This document describes systems and techniques for correlating andretrieving user contact identifiers with a handle.

BACKGROUND

The development of modern communications technologies has enabled peopleto communicate by more and richer mechanisms—via e-mail, text messaging,video conferencing, posting content to web pages, microblogging, andother such expanding mechanisms. This increase in communicationmechanisms, however, brings about a concomitant increase in thecomplexity of determining someone's contact information. For example, aparticular internet user may have a home telephone number, a cellulartelephone number, a work telephone number, a work e-mail address, apersonal e-mail address, a home page, a blog, an IM account, and othersuch mechanisms for communicating with others. This multitude ofconnection mechanisms can make it difficult to keep track of contactinformation for a number of friends or acquaintances. Also, it can behard to get and enter all such information from a new acquaintance. Thatis why, frequently, people tell a new acquaintance to call theirtelephone number or e-mail them, so that they can capture, respectively,the other user's telephone number or e-mail address.

Such difficulties become even more pronounced across a user's lifetimeas they move from situation to situation. For example, each time a userchanges jobs, they generally lose their old work telephone number ande-mail address and acquire new ones. This may result in a businesssocial networking site “pinging” all of their acquaintances to announcethat the acquaintances should check for the new contact information. Itmay also result in acquaintances who are not updated in such a mannergetting a wrong number or an e-mail bounce-back when they try to reachan old acquaintance.

SUMMARY

This document describes techniques for correlating and retrieving ahandle with contact identifiers. In general, a user may be contactedusing a single handle that triggers communication by a variety ofdifferent communication mechanisms using a plurality of communicationmodes, where modes are different types of communication connections suchas telephone, e-mail, text messaging, and other such modes. For example,a single alphanumeric string can be submitted by a party wanting tocontact the user, whether the party wants to make the contact viatelephone, e-mail, chat or other such mode of communication. Thus, forexample, a third party can “dial” the handle using a telephone and thehandle will lead to a service that translates the handle into anothertelephone number where the user can currently be reached. In a similarmanner, a third party can use the handle plus a common domain (e.g.,gmail.com) to e-mail the user, and the e-mail message can be forwarded,using rules defined by the user, to another e-mail account or addressfor the user. The handle can also be used to push updates regardingvarious contact mechanisms out to the third party when a user changessuch information, such as by sending a new vcf card to the third party.

Such systems and techniques may provide one or more advantages incertain implementations. For example, a user can provide a single pointof contact to which acquaintances may point in order to be updatedregarding contact information for various contact mechanisms for theuser. Also, the acquaintance may be permitted to generally ignorechanges in individual contact mechanisms, such as when the user switchesto a new job and receives a new work telephone number and new worke-mail address, and simply remember a handle for their acquaintance,where the handle does not need to change every time one of the contactmechanisms that underlies the handle changes. Rather, the handle, bywhatever mode submitted, may be mapped to the various communicationmodes and contact mechanisms (such as e-mail addresses and telephonenumbers) for a user, so that the user can keep those mechanisms updatedwithout bothering the user's acquaintances. In addition, the user mayestablish various routing rules to control how the user is contacting,and via which contact mechanism, where such rules may depend at least inpart on the time of day or day of the week when the contact is made, theidentity of the person seeking to make contact, and other similarfactors that may affect a user's decisions regarding how to becontacted.

In a first general aspect, a computer-implemented method is described.The method includes obtaining, at a computer system, a plurality ofdifferent contact identifiers for a computer account holder, wherein theidentifiers represent a plurality of different communication modes;identifying a handle for the account holder, wherein the handle isassociated with a uniform resource locator; and correlating the handlewith the plurality of contact identifiers, and storing the handle andplurality of contact identifiers together so as to permit retrieval ofthe contact identifiers in response to identification of the handle.

In a second general aspect, a computer-implemented communicationmanagement method is described. The method includes receiving at acomputer system a handle for an account holder submitted by a computingdevice; providing, for presentation to the computing device, a group ofcontact identifiers from a plurality of different communication modes;and electronically connecting the computing device to the account holderby one of the plurality of communication modes in response to aselection by the computing device of a contact identifier correspondingto the one of the plurality of communication modes.

In a third general aspect, a computer-implemented communication systemfor identifying contact identifiers for an account holder is described.The computer-implemented communication system includes an interface toobtain a plurality of different contact identifiers for a computeraccount holder, wherein the identifiers represent a plurality ofdifferent communication modes; an account manager to identify a handlefor the account holder, wherein the handle is associated with a uniformresource locator; and a correlator to correlate the handle with theplurality of contact identifiers, and store the handle, the plurality ofcontact identifiers together so as to permit retrieval of the contactidentifiers in response to identification of the handle.

In a fourth general aspect, a computer implemented communication systemfor assisting in forming communication sessions is described. Thecomputer implemented communication system includes an interface toreceive a handle from a user of a computing device, wherein the handleis associated with a uniform resource locator; a central databaseassociating a group of contact identifiers for an account holder to theuniform resource locator; and a communication mode selector to receive amode indicator and one or more contact identifiers from the database andto select the contact identifier using a communication modecorresponding to the mode indicator to connect a third party forcommunication with the account holder.

In a fifth general aspect, a computer implemented communicationmanagement method is described. The method includes electronicallyproviding a user account handle; retrieving a plurality of contactidentifiers correlated with the user account handle; displaying theplurality of contact identifiers, each contact identifier beingdifferent from another contact identifier and associated with a contactrule; and receiving, at a computing device, at least one modification ofone of the contact identifiers.

The details of one or more embodiments are set forth in the accompanyingdrawings and the description below. Other features, objects, andadvantages will be apparent from the description and drawings, and fromthe claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a conceptual diagram of a system for retrieving a user'svarious contact identifiers correlated to a handle.

FIG. 2A is a schematic diagram of a system for retrieving a user'svarious contact identifiers correlated to a handle.

FIG. 2B is a sequence diagram depicting examples of interactions betweenclients and servers.

FIG. 3 is a schematic diagram of a system for correlating a handle withcontact identifiers.

FIG. 4A is a flowchart showing actions taken to correlate a handle withcontact identifiers.

FIG. 4B is a flowchart showing actions taken to retrieve a user'scontact identifiers correlated with a handle.

FIG. 5A is a sequence diagram for generating a user account to correlatea handle with a user's contact identifiers.

FIG. 5B is a sequence diagram for retrieving a user's contactidentifiers correlated with a handle.

FIG. 6A is an exemplary universal business card.

FIG. 6B is a screenshot of a web page for retrieving a user's contactidentifiers correlated with a handle.

FIG. 6C is a screenshot of a web page for correlating a handle withcontact identifiers

FIG. 6D is a screenshot of a web page displaying a user's contactidentifiers correlated with a handle.

FIG. 7 shows an example of a computer device and a mobile computerdevice that can be used to implement the techniques described here.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

In general, this document describes mechanisms for providing a singlepoint of contact for a user so that third parties may contact the userthrough various forms of communication without having to use more thanthe single point of contact. Contact information for the single point ofcontact may be supplied to third parties who are acquaintances of theuser, in one example, through a website that the third parties mayvisit. The contact information may be tailored to individual thirdparties or groups, e.g., family may obtain one set of contactinformation, friends another set, and work contacts a third set ofcontact information (where the various sets may overlap). The user mayalso update a particular contact identifier, for example, a work phonenumber, without needing to update customers, vendors, or co-workers ofthe contact information change, because the single point of contact maystay fixed while the various contact mechanisms that are made availablethere to third parties may change. The single point of contact may bedesignated by a handle, such as an alphanumeric code that can beresolved to a particular web page or IP address. The handle may be aunique string appended to a particular URL as a pointer to a filecontaining the user's contact information.

A third party may also retrieve information and “slurp” a user's contactinformation, in the form of the particular contact mechanisms, withoutthe need to copy the information on an individual basis. The third partymay store the information for later use on various client devices, e.g.,a home computer, an e-mail account, a mobile device, or a home phone, orthe third party may use the handle each time to contact the user.Likewise, some clients may allow the third party to choose the method ofcontact for the user and choose the handle in order to have the clientretrieve the particular contact identifier correlated with the handle.For example, instead of providing an individual contact mechanism like awork phone number, the third party can simply supply the invarianthandle along with an argument like “work,” and a service may route thethird party to the user via the user's current work telephone number. Inthis manner, a user may update contact information on a regular basiswithout the concern that various friends, family, or work associates maybe unable to contact the user.

FIG. 1 is a conceptual diagram of a system 100 that connects third party102 to a user 114 of the system 100 by one of a number of contactmechanisms, where the particular contact mechanism could be specified bythe third party 114 or the user 102. In general, the system 100 mayallow the third party 102 to provide a single handle, or perhaps thehandled plus additional basic information, in order to contact the user114 by various mechanisms, without having to know the contactinformation for those various contact mechanisms. The contact mechanismsmay also take a variety of formats, such as telephone, e-mail, and thelike.

In the example system 100, a third party 102 is shown submitting to thesystem 100 a handle 106, which in this example is a 10-digit telephonenumber. The third party 102 in this example is trying to contact user114 (whether directly, by leaving a message for user 114, or by beingshown content such as a web page that user 114 has generated) by one ofa variety of mechanisms. Although the handle 106 takes the form of atelephone number here because users are accustomed to memorizing suchnumbers and to assigning them as contact mechanisms, the handle 106 cantake a variety of forms that “look” different than a telephone number,such as by looking like the person's full name or like an e-mailaddress.

Various contact identifiers 104 are shown by which user 114 may becontacted. These contact identifiers are from a plurality of differentmodes of communication, such as telephone, e-mail, and others. A mode ofcommunication is a particular distinct type of communicating, where eachuser may be contacted by one or more contact identifiers for anyparticular mode. For example, the user reflected in FIG. 1 has threetelephone numbers, and thus three contact identifiers for the telephonemode of communication (in addition to the handle 106, which may act likea telephone number).

A routing mechanism 110 controls how the third party 102 communicateswith the user 112 when the third party 102 provides the handle 106 tothe system 100. In particular, the handle may be correlated with aparticular contact mechanism of a particular mode of communication. Withrespect to the telephone mode of communication and telephone numbers ascontact mechanisms, the handle may correlate much as a telephone handleis correlated to other telephone modes of contact in a system such asthe known GRAND CENTRAL system. However, the handle in this example mayalso be correlated with multiple modes of communication, so that whenthe third party 102 provides the handle, the third party 102 isconnected by a technique other than a telephone call, such as viae-mail. As a result, the handle may, in certain implementations, be auniversal handle for contacting the user 114, by whatever desired mode.

The particular mode of communication may be set by the user 114, by thethird party 102, or by one or more rules such as rules defined by theuser 114. For example, the user 114 may manually set a flag thatindicates their currently-preferred mode of receiving communications. Asone example, the user 114, as they enter a large meeting or anotherlocation in which a telephone call would be inappropriate, may log intoa system and indicate that their preferred mode of communication is oneof a number of textual modes, such as e-mail or chat. The third party102 may indicate the preferred mode by accompanying their submission ofthe handle 106 to the system with a mode indicator. For example, thethird party may type “123-456-7890 email” along with text for an e-mailmessage in order to e-mail another user. The system 100 will theninterpret the request appropriately and form an e-mail message to theuser 114 at an e-mail address that the system has determined to be anappropriate e-mail address. For example, if the system 100 matches adomain relating to the sender to a business-related domain for the user114, the system 100 may send the e-mail message to the user's worke-mail account. In contrast, if the domain is a domain such as “aol.com”or a domain on a whitelist for the user (such as an old college friend),the e-mail message may be sent to a personal account.

The user 114 may also establish rules of various forms for selecting acommunication mode. For example, if the user does not like to receivetelephone calls or check voice mail over the weekend, but does carry asmart phone with them, they may set their mode of communication toe-mail, so that third parties are induced to send them e-mails. A mix ofthird party 102 defined mode and user 114 defined contact identifierunder a mode may also be employed. For example, a third party 102 mayidentify e-mail as the mode of communication, and then user-definedrules may determine which e-mail account, from multiple e-mail accountsassociated with the user, is to receive the e-mail. Responses by theuser 114 may likewise be generalized to reflect the handle in the “from”field, rather than the particular e-mail account used by user 114.

Where the third party 102 does not dictate the mode of communication andthe user's preferred mode of communication does not match a mode thatthe third party initially selects, the third party 102 may be promptedto user the other mode. For example, the third party may initially dialthe handle 106 as part of a telephone call. The system 100 may determinethat the user 114 currently wants to be contacted by e-mail, and maythus play a message such as “If you would like to contact Bob at themoment, please e-mail him at xyz@xyz.com.” The system 100 may alsotransmit data to the third party's computing device so as to start aform e-mail that is automatically addressed to the user 114, or maysimply send an e-mail from the user's account to the third party 102(e.g., where the third party's telephone number can be determined fromANI or caller ID data, and can be correlated to an e-mail address forthe third party 102, such as through an address book for the user 114),so that the third party 102 can simply reply to the incoming e-mail.

In some implementations, the mode indicator may be preselected based onthe client device that the third party 102 uses. For example, if thethird party 102 is using a mobile phone to transmit the handle 106, thesystem 100 may directly connect the third party 102 to the user 114 viathe telephone number in the contact identifiers 104. Alternatively, ifthe third party's client device has more than one mode of communication(e.g., a smart phone), the third party 102 may be provided with variousmodes of contacting the user 114, including phone, web page, IM, ande-mail, all associated with the handle 106.

As noted above, in this example, the handle 106 includes a telephonenumber or is in the form of a telephone number, “123-456-7890.” The useof a telephone number may be useful for an individual to remember, giventhat telephone numbers are commonplace in that many countries use Arabicnumerals to some extent. Alternatively, the handle 106 may include analphanumeric string. For example, the handle 106 may be the user's nameor the user's preferred e-mail address or street address. Likewise, thehandle 106 may be a portion of the user's full telephone number with acountry or state code, or both, e.g., “US-MN-456-7890.”

While the contact identifiers 104 are shown here conceptually as avirtual list from which a router 110 selects one identifier forconnecting the third party 102 to the user 114, they may also beactually displayed to the user 114 or third party 102 when such a partyaccesses a web page in the form of a contact page and directs theirattention to the user 114, such as by entering the handle 106 for theuser 114 or by entering one of the contact identifiers 104 for the user114. Such a contact page can show contact identifiers that are a subsetof a full set of contact identifiers. For example, if the third party102 is a new acquaintance to the user 114, the user 114 may provide fora small subset of contact identifiers to be shown to the third party102, such as a work phone number, work e-mail address, and website. Insome implementations, the user 114 can provide the third party 102 witha password to access a larger subset of the full set of contactidentifiers. Likewise, the user may provide group-specific passwords toprovide different subsets of the full set of contact identifiers todifferent groups, e.g., family, friends, coworkers, and acquaintances.In one implementation, access to contact identifiers may be coordinatedwith user statuses in a social networking site, where strangers may beshown limited contact identifiers, acquaintances (which have beenaffirmatively approved by the user) may see additional identifiers, andan “inner circle” of friends may see even more identifiers (e.g., homephone numbers and the like).

Similarly, the third party's contact identifiers may already beassociated with the user's account. For example, the user 114 may havean address book of contacts stored as a part of his or her user account.Contact identifiers for the third party 102 may be associated with anentry for the third party 102 in the address book. For example, a clientdevice for a third party may transmit an identifier, e.g., an e-mailaddress, telephone number, or IM account name, with the handle 106. Theidentifier may be associated with a group access level or an individualaccess level for a subset of contact identifiers.

In these manners, one or more third parties may use a handle such ashandle 106 to contact user 114 and/or to see information about the user114. In one example, the handle 106 is provided so as to connect thethird party 102 to the user 114 via one of a number of different contactidentifiers and modes of communication. In another example, the handle106 is used to allow the third party 102 to see information about theuser 114, such as various contact identifiers associated with the user114. As a result, the third party 102 can take advantage of a number ofdifferent communication techniques vis-à-vis the user 114 without havingto memorize or otherwise manage a large number of different contactidentifiers, each of which may change over time. Instead, the thirdparty 102 can, in proper implementations, simply record

FIG. 2A is a schematic diagram 200 of a system for retrieving a user'svarious contact identifiers correlated to a handle. In general, thesystem 200 permits various third parties to access and retrieve contactidentifiers for users that have user accounts, using a single handle toidentify a particular user account. The system 200 includes a thirdparty 202 using a client device 204 to transmit a request to a contactidentifier server 206, the request including a handle 208. The contactidentifier server 206 may store the handle 208 with a contact page 210along with contact identifiers 212 for a user account.

The contact identifier server 206 may store contact identifiers for atleast one user account correlated to a handle 208. A plurality ofcontact identifiers may be correlated with a single handle, and aplurality of different communication modes may be represented by thoseidentifiers. In some implementations, the contact identifier server 206may automatically update data on a client device 204 for a third partywhen a particular user account is updated. For example, the contactidentifier server 206 may receive data from the user for the account toupdate a phone number. The contact identifier server 206 may store thedata and send an automatic update to any third party device associatedwith the previously stored phone number, such as users who areidentified as friends of the main user in a social network. For example,where a main user has changed their work phone number, the contactidentifier server 206 may send information reflecting that changednumber to accounts of acquaintances of the main user, e.g. by sending anew user .vcf card with the new work phone number for MICROSOFT OUTLOOK.

In some implementations, the update may be sent upon a request sent fromthe third party to the contact identifier server 206. For example, ifthe client device 204 transmits a request for a user's IM contactidentifier, the contact identifier server 206 may update the clientdevice 204 with a new IM contact identifier when the contact identifierserver 206 connects the client device 204 to a user's device tocommunication through instant messaging. Likewise, the new IM contactidentifier can be transmitted before the connection is made, while theconnection is occurring, or after the instant messaging connection hasended.

Alternatively, the handle 208 may be the only identifier saved on thethird party's client device 204. The handle 208 may be stored in a listof handles on the client device 204, where each handle corresponds to aparticular acquaintance of the third party, and the third party makescommunication connections simply using the various handles. For example,on a mobile phone, the third party may have an address book of handlesfor various user accounts, including the name of a particular userassigned as a pseudonym for each handle. In some instances, the thirdparty may be able to designate a particular alias for a user, e.g., anIM screenname or an image. The handle 208 may be part of a UniformResource Identifier, e.g., a URL containing the handle 208 5555551234,“http://www.exampledomain.com/5555551234.”

The third party's client device 204 may be one of a variety of clientdevices, such as a mobile device, a smart phone, a laptop computer, adesktop computer, or a landline. The client device 204 may provide amode identifier to the contact identifier server 206 so that the contactidentifiers transmitted to the client device are limited to contactidentifiers with which the client device 204 can make a connection. Forexample, the client device 204 can be a laptop computer with a VoIPapplication, an e-mail application, a web browser application, and an IMapplication. The contact identifier server 206 may then transmit contactidentifiers including telephone numbers, e-mail addresses, blogs,websites, and an IM account name compatible with the particular IMapplication.

FIG. 2B is a sequence diagram 250 depicting examples of interactionsbetween a caller 252, a contact identifier server 254, and a friend 256of the caller 252 to retrieve for the caller 252 contact identifiersusing a handle 260 for the friend 256. The sequence diagram shows thefriend 256 providing contact identifiers to the contact identifierserver 254, the caller 252 accessing information from the contactidentifier server 254 using the handle 260, and the caller 252contacting a friend 256 using the handle 260. In some implementations,both the caller 252 and the friend 256 may have accounts with contactidentifiers stored on the contact identifier server 254.

In the figure, the friend 256 initially submits information (indicatedby Arrow A₁) to the contact identification server 254. The friend 256provides his contact identifiers 258 (indicated by Arrow A₂) correlatedto a handle 260. The caller 252 transmits a request (indicated by ArrowB) to the contact identifier server 254 to access information for thefriend 256. The caller 252 is directly connected to the friend 256(indicated by Arrow C) using a contact identifier provided by thecontact identifier server 254.

In some implementations, the contact identifiers 258 may also be storedon a personal computing device. For example, a computing device used bythe caller 252 may store one or more of the contact identifiers that thecontact identifier server 254 may grant to the caller 252. The computingdevice may use the stored contact identifiers to connect to a computingdevice associated with one or more of the contact identifiers correlatedwith the user's handle 260. For example, the caller 252 may have a cellphone that receives a cell phone number for his friend 256 from thecontact identification server 254. The cell phone may store the cellphone number for his friend 256. The cell phone can use the receivedcell phone number to connect to a cell phone of the friend 256.Likewise, the computing device may compare a stored list of contactidentifiers with the contact identifiers 258 provided by the contactidentifier server 254 to update one or more contact identifiers that thefriend 256 may have updated since the caller 252 last sent a request tothe contact identifier server 254.

Alternatively, the connection may be made from the caller 252 to thefriend 256 through the contact identifier server 254. This connectionmay be made during the grant of the request for access or after therequest for access is granted. For example, the friend 256 may have apreferred method of contact associated with his user account, e.g., ane-mail address. The caller 252 may request information using a smartphone, and the contact identifier server 254 may provide the smart phonewith the e-mail address. An e-mail application on the caller's computingdevice may receive the e-mail address and generate a new message usingthe e-mail address in the “To:” field. Similarly, if the caller 252wishes to call the friend 256, the caller 252 may designate “phone” as amethod of contacting the friend 256. The contact identifier server 254can receive this request along with the handle 260 and connect thecaller 252 with the friend 256 via a telephone connection.

In some implementations, the caller 250 can access contact identifiers258 from the contact identification server 254 through a query, usingthe friend's personal information to gain access to the account for theuser. For example, the caller 252 may not know the handle 260. If thecaller 252 provides personal information for the friend 256, e.g., aname, an e-mail address, or a telephone number, the contact identifierserver 254 may provide access to one or more other contact identifiersto the caller 252. For example, the caller 252 may already have the worke-mail address for his friend 256, but not have the work phone numberfor his friend 256. If the caller 252 provides the work e-mail addressto the contact identifier server 254 in a request for the work phonenumber, the work e-mail address may act as a password or securityidentifier to the contact identifier server 254. The contact identifierserver 254 may associate the work e-mail address with the work phonenumber or a work address. The work e-mail address may also be associatedwith a cell phone number. In some implementations, the contactidentifier server 254 may be associated with a website similar to whitepages, where the website provides a search tool to find a handle for auser account. For example, if the caller 252 enters the friend's name,the website may provide the handle 260.

FIG. 3 is a schematic diagram of a system 350 for correlating a handlewith contact identifiers, and for retrieving the contact identifierscorrelated with the handle. In general, the system 350 permits users tocreate user accounts that are represented to the outside world by ahandle and that internally correlate to a plurality of different contactidentifiers representing a plurality of communication modes. The system350 then lets other users search user accounts for information aboutpeople or organizations they are trying to contact, where the system mayprovide such searching users with the handle, and the users may then usethe handle to contact another user in various manners and using variousdifferent communication modes.

A user 352 may interact with the system 350 using a computing device 354to connect with a server 356. Such communication may occur over one ormore networks (not shown), which may include portions of the internet.The server 356 may be various devices, for example, a single computingdevice, multiple servers in a cluster, or multiple computing devicesspread over the internet in a cloud. The server 356 may assist inproviding contact identifiers to the computing device 354. Likewise, theserver 356 may correlate contact identifiers with a handle for a useraccount. The computing device 354 may be provided with one or morecommunication applications such as a telephony application, IMapplication, and e-mail application, which may employ a handle to begina communication session with a target user that corresponds to thehandle.

The server 356 contains a number of components that permit it to providea user's computing device 354 with a connection to contact identifiersthat have been correlated with a handle. For example, an interface 358may handle communications with remote devices such as computing device354. The interface 358 may, for example, receive requests from thecomputing device 354 for contact identifiers correlated to a handle. Theuser 352 may send a handle, such as “612-555-1234,” to request contactidentifiers (in the form of e-mail addresses, telephone numbers and thelike) for a particular user account holder. The contact identifiers mayrelate to various modes of communication, e.g., telephone, e-mail,instant messaging, blogs, and websites that are associated with a userwho corresponds to the handle. The interface 358 may receive this handleand provide contact identifiers in response. The requesting user mayemploy such identifiers to update contact information for the other userstored in the computing device 354 or in a contact database associatedwith a user account for the user 352.

Once the interface 358 receives data, it may transmit the data toanother component such as an account manager 360, which is responsiblefor providing consistent and personalized interaction with registeredusers of system 350. The account manager 360 may identify a handle for aparticular user in the received data. The handle may be correlated to auniform resource locator (URL). For example, the handle may be includedin a URL for a website: “http://www.examplehandle.com/612-555-1234.” Theaccount manager 360 may also identify passwords for particular accounts.For example, the user 352 may provide a password to set up or edit auser account. Likewise, users may provide passwords to gain access tovarious subsets of contact identifiers correlated to a particularhandle. For example, the user account can be set so that users with a“family” password have access to a mobile phone number and home phonenumber, but not a work phone number.

The server 356 may also include a correlator 362 that correlatesreceived handles with contact identifiers relating to the handles. Inparticular, the correlator 362 may be programmed to perform a look-upfunction on the handle, and to return a list of contact identifiers forthe handle, where the list may be limited based on an authorizationlevel of a user that is requesting the information. For example, onlyclose friends that have full authorization may be shown a contactidentifier for a home telephone number or very private e-mail account.The correlator 362 may also cause the handle, the contact identifiers,and pointers connecting the handle to the contact identifiers to bestored for later use. The correlator 362 may also correlate passwordswith particular handles or particular contact identifiers. In someimplementations, the correlator 362 may store the user account data in asingle database. Alternatively, the correlator 362 may store the useraccount data in multiple databases.

A database storing information for the server 356 may have various datastores that are used to correlate lists of contact identifiers for useraccounts to the corresponding uniform resource locators for suchaccounts. In some implementations, the database may include a passwordsdata store 366, a contact information data store 368, and a handles datastore 370. The passwords data store 366 may contain passwords for theuser account, including a password for editing the contact identifiersfor a particular user account (e.g., where the “owner” of the account isaccessing the information) and passwords for accessing various contactidentifiers for a particular user account (e.g., where acquaintances ofthe “owner” are seeking information). The contact information data store368 may contain contact identifiers for various users. In someimplementations, the contact information data store 368 may also containdata regarding preferences for particular contact methods, groups forparticular contact identifier subsets, and other user-preference data.The handles data store 370 may store handles for various user accounts.The handles may be integers, as in telephone numbers, alphanumericstrings, images, or other unique identifiers. Generally, the handlesdata store 370 and the contact information data store 368 may becombined in the form of a look-up table that is indexed according toparticular user handles.

The server 356 may also include a communication mode selector 364 toreceive a mode indicator. The mode indicator may provide information asto the selection of communication method that has been selected formaking contact between user 352 and another user. For example, thecommunication mode selector 364 may receive a “mobile” mode indicatorfor the user 352 indicating that the user 352 wants to call the otheruser's cell phone. Such a mode indicator may accompany the handle, asmay other mode indicators such as “e-mail” and “home phone”, so thatuser 352 merely needs to remember or store the single handle, and thenadd a general description of the communication mode—rather than havingto remember or store a separate identifier for every way in which theuser 352 can contact the other users.

Also, certain aspects of the mode indicator can be controlled by thetarget user either explicitly or via contextual rules. For example, theuser 352 may use a telephone to dial another user, and the call may berouted to server 356. The server may recognize the call, via DNISinformation received from the telephone system or from other data, asbeing directed to the particular handle, and may access informationabout the user that is the target of the call. For example, the systemmay determine that, at the current time, the target user would prefer toreceive e-mail messages. As a result, the server 356 may use a voicesynthesis module to speak a message to user 352, such as “The user youare calling would prefer to receive e-mail for the next 24 hours. Press1 to leave a voice message that will be transcribed into an e-mailmessage or e-mail the user at bob@acme.com.”

The communication mode selector 364 may also receive one or more contactidentifiers from the database, e.g., the contact information data store368. Where multiple contact identifiers are received for a particularmode, the appropriate mechanism for contacting the target user by thatmode may need to be determined. For example, the communication modeselector 364 may receive a home phone number, a cell phone number, a URLfor a website, and an e-mail address for a home e-mail account. Thecommunication mode selector 364 may initiate a communication sessionbetween the user 352 and the other user according to one of thecommunication modes. For example, the communication mode selector 364may use a telephone mode indicator and then look at the target user'sschedule to select the cell phone number for the other user, and causethe user 352 to be connected to the cell phone of the target user. Theschedule may be set by rules provided by the target user, such as rulesdefining that the target user is to be contacted at his or her worknumber during work hours and at his or her cell phone after hours (andperhaps that all calls should automatically roll to a central voice mailor voice mail to e-mail transcription service during sleeping hours).Thus, the communication mode selector 364 can select a particular modebased on inputs from an initiating party, from a target party, or fromrules set up by or selected by one of the parties, and can also select aparticular contact identifier from multiple identifiers that may existfor a particular communications mode, by which to complete thecommunication.

FIG. 4A is a flowchart showing an example of a process 400 forcorrelating a handle with contact identifiers. Such a process may beemployed by a user of a central connecting service who wants toinitially set up a count by selecting a handle and then supplying all ofthe user's various contact identifiers to be correlated to the handle.The process 400 shows one example of generating a user account withcontact identifiers across multiple modes of communication, correlatedwith a single user handle. The single user handle allows the user'scontacts to communicate with the user in various communication modeswithout requiring the contacts to store information regarding the user'svarious contact identifiers separately or having to update the contactidentifiers as the user changes individual contact identifiers.

At an initial step, the process 400 obtains (402) identifiers for aplurality of contact identifiers for a computer account holder. Forexample, the identifiers may be unique identifiers for particularmechanisms of communication under various communication modes for aparticular user. The communication modes, e.g., blogs, instantmessaging, telephone, mail, and e-mail, can each have multiple uniqueidentifiers for each of the mechanisms by which the user can becontacted. For example, in instant messaging, a user may have an MSNMESSENGER identifier, an AMERICA ONLINE Instant Messenger identifier,and a GOOGLE TALK identifier.

The process 400 then identifies (404) a handle for the account holder.For example, the handle may be a string that the user selects whensetting up his account, such as the user's full name or a particularphone number. The handle can also be selected by the process for theuser, such as in the manner that telephone numbers are provided forselection by a user seeking a new telephone number. In someimplementations, the handle may be correlated to a URL. For example, theURL may be a website address for a unifying presence site, e.g.,“http://www.exampleonesite.com.” The correlated handle may navigate to aunique page designated for the account holder. For example, the URLcorrelated with the handle may be“http://www.exampleonesite.com/612-555-1234.”

The process 400 then correlates (406) the handle with the plurality ofcontact identifiers. For example, the user's instant messenger accountsand e-mail addresses may be correlated with the handle “612-555-1234.”In some implementations, the process 400 may store the handle, theplurality of contact identifiers, and pointers connecting the handle tothe plurality of contact identifiers in a database. For example, thesystem 350 described in FIG. 3B may store the handle, the plurality ofcontact identifiers, and the pointers in multiple data stores, e.g., thehandles data store 370 and the contact information data store 368. Also,the handles may be stored in an index field of a look-up table, with thecontact identifiers stored in a target field of the same table so that asimply look-up on the handle field may return the corresponding contactidentifiers.

In this manner, a user of a computing system may register their contactinformation, which may span multiple mechanisms for connecting andmultiple modes of communication, with a central service. The service maythen correlate such mechanisms with a single common handle by which thevarious forms of information may more easily be recovered or used byother users, such as by being used to connect to the first user in acommunication session.

FIG. 4B is a flowchart showing an example of a process 420 forretrieving an account holder's contact identifiers correlated with ahandle. Such retrieval may be performed by someone searching for theuser/account holder discussed in FIG. 4A or by an acquaintance of suchan account holder. The acquaintance may have received the handle fromthe account holder, and may want to find out the latest contactinformation for the account holder. The process 420 shows one example ofreceiving a handle from a user and using the handle to identify contactidentifiers for a particular account holder, though other examples mayalso be used. The handle allows the user to communicate with the accountholder in various communication modes while only requiring the user toprovide the single handle.

At an initial step, the process 420 receives (422) a handle for anaccount holder submitted by a user of a computing device. For example,the computing device may submit the handle “ChakaKhan”—a name that isunique enough that it alone could serve as a unique identifying handle.The handle can provide a unique identifier for the process 420 toidentify a particular account of an account holder. Likewise, theprocess 420 may request a password before providing information aboutother contact identifiers, such as a home telephone number or worke-mail address.

The process 420 then provides (424) a list of contact identifiers from aplurality of different communication modes to the user of the computingdevice. For example, the list of contact identifiers may include a homemailing or e-mail address, a work address, a work website, a Twitteraccount identifier, and a cell phone number. In some implementations,different subsets of the list of contact identifiers may be provided.For example, the process 420 may only provide the work address and cellphone number to a person given “Work” group access, while a persondesignated as belonging to a “Friend” group may be provided the homeaddress and the Twitter account. Groups may be designated throughvarious mechanisms. For example, the process 420 may determine the levelof access through password requests or the process 420 identifying theclient device used to request contact identifiers.

At box 426, the process connects the user to the account holder by oneof a plurality of communication modes. For example, a work e-mailaddress may be propagated to a word processing document, with theaddress field preset to the account holder's work e-mail address. Insome implementations, the connection may be made in response to aselection by the user of the computing device of a contact identifiercorresponding to the one of the plurality of communication modes. Forexample, the user may choose “Feed” to read the most recent Twitter postby the account holder.

In some implementations, the handle may be correlated to a URL. As in anexample for FIG. 4A, the URL may be a website address for a unifyingpresence site, e.g., “http://www.exampleonesite.com.” The process 420may receive a request with the URL“http://www.exampleonesite.com/612-555-1234”, retrieve the account for“612-555-1234”, and map the request to a contact identifier included inthe account.

FIG. 5A is a sequence diagram for depicting an example of interactions500 between an account holder 502 in a communication system and a server504. The process shown here is similar to that shown in FIG. 4A, andprovides a more explicit indication of exemplary manners in which anaccount holder and a server system can interact in correlatingidentifiers with a single user handle. In general, the interactionsinvolve a server generating a user account, assigning a handle to theuser account, and correlating a number of contact identifiers with theaccount.

In the figure, the account holder 502 initially transmits identifiers(box 506), such as e-mail addresses, telephone numbers, and instantmessage accounts, to the server 504. Such a transmission may occur afterthe account holder 502 initially establishes his or her account. Theserver 504 then receives the identifiers (box 508) and determines ahandle (box 510) for the account holder 502. In some implementations,the account holder 502 provides input to the server 502 regarding achoice of handles. For example, the account holder 502 may provide aninitial suggestion of a handle along with the first identifiers that theaccount holder transmitted to the server 504. Alternatively, the server504 can also provide a handle without input from the account holder 502.

The server 504 then correlates the handle with the identifiers (box512). Such correlation may occur by storing the handle and theidentifiers together in a look up table so that entry of the handle tothe table causes the identifiers to be provided. At box 514, the server504 stores the handle and the identifiers in a database such as in alook up table. In certain implementations, pointers from a handle to theidentifiers may also be stored. As shown in FIG. 3, the identifiers andthe handle need not be stored in the same location, though they may. Insome implementations, the pointers may be stored with the handle, or,alternatively, the pointers may be stored with the identifiers. Thepointers may also be stored in a third location, separately from boththe identifiers and the handle.

Once the server 504 has stored the account information, the server 504transmits a confirmation (box 516) that the handle and identifiers (andoptionally the pointers) have been recorded and correlated to eachother. The confirmation may be a complete listing of all theinformation, a confirmation containing the handle and identifiers, orsimply the handle. The account holder 502 then receives the confirmationat box 518. The confirmation can be received in various formats,including an HTML-embedded e-mail, an instant message, a web page, atext message on a cell phone, or a generated voice message.

FIG. 5B is a sequence diagram that depicts an example of interactions530 between a user 532, an account holder 534, and servers 536. By theprocess, a third party use may submit a handle to a central system wherethe handle corresponds to an account holder in the system. The systemthen identifies a communication mode and mechanism by which the accountholder should be contact, and automatically carries out the necessarysteps to cause such communication to occur. As such, the process shownhere is similar to that shown in FIG. 4A, and provides a more explicitshowing of exemplary manners in which a third party can contact theaccount holder without having to remember or provide detailed contactinformation. In particular, the servers 536 may be part of a unifyingidentifier system and may communicate with various client devices, suchas cell phones, laptop computers, landlines, and smart phones to providean ease of communication between the user 532 and the account holder 534and also to more accurately provide the user's and account holder'spreferred methods of communication. In this manner, the connection maybe easier for the user 532 because the user 532 need only remember asingle handle and perhaps some generic control information (e.g., acommon term that identifies the mode of communication), and in certainimplementations, the particular contact identifier may be kept anonymousfrom the user 532. For example, where the contact is made through theservers 536, an actual e-mail address or telephone number may be maskedusing a system address or number via a bridging mechanism similar tothat for e-mail communications using on-line services such asCRAIGSLIST.

In the example process, the user 532 initially submits to a group ofservers (536) a handle for an account holder (box 538). The servers 536receive the handle (box 540), such as a telephone number appended to aURL. The servers 536 then determine contact identifiers (box 542)correlated to the handle. The contact identifiers may be selected from alarger group of contact identifiers for the account holder 534, and mayinclude one or more identifiers within each of a plurality ofcommunication modes. For example, the user 532 may be an unknownindividual to the account holder 534. Therefore, the account holder 534may store a setting that the user 532 will not receive a home telephonenumber that is stored as one of the identifiers.

At box 544, the servers 536 then transmit a list of contact identifiersto the user 532 and the user 532 receives the list of contactidentifiers (box 546). The user 536 may receive the list through anapplication programming interface (API) so that the contact identifierscan be updated in a client device that the user 532 is using to connectto the servers 536. In this manner, the user 532 may more readilycontact the account holder 534 through a variety of methods ofcommunication. For example, the user 532 may wish to call the accountholder 534 to discuss an e-mail that the user 532 plans to send to theaccount holder 534 during the telephone conversation.

The user 532 then selects one of the contact identifiers (box 548). Insome implementations, this determination is made through the user'sclient device that connects to the servers 536. In otherimplementations, the determination is made because the user 532 is onlygranted access to one contact identifier, or the account holder 534 hasonly provided one contact identifier. Alternatively, the user 532 mayselect from the list of contact identifiers provided. The servers 536receive the selection (box 550) of contact identifiers. The servers 536then attempts to connect the user 532 to the account holder 534 bycontacting the user 532 (box 552) and contacting the account holder 536(box 554). The contact may be a VoIP connection or an instant messagingchat session. The user 532 receives the contact (556) and the accountholder 558 receives the contact (558). If both the user 532 and theaccount holder 534 accept the contact, the user 532 and the accountholder 534 are connected (560). The connection may be a directconnection, such as through landlines, a routed connection through theservers 536, or a connection through a third party service, such as aninstant messaging connection.

In certain implementations, the users may be connected directly, such asby the user 532 submitting a handle and receiving a telephone number inreturn. The telephone number then may be dialed automatically by theuser's client device, such as via an automatically executing dialinglink in a mark up document sent by the server 536.

The connection may also be made automatically through the servers 536.For example, the servers 536 may include servers for completing a VOIPtelephone connection, and may carry out the necessary steps to connectthe user 532 and the account holder 534. Such an implementation isparticularly well-suit for keeping contact identifiers of the accountholder 534 private, and not sending any information about theidentifiers (or at least some of the identifiers) to the user 532. Suchan approach may be useful when an account holder is working from homeand would like to be reached at home, but does not want people callinghis or her work number to get access to his or her home number.

FIG. 6A is an exemplary universal business card 600. The universalbusiness card 600 may be in an electronic or hard copy format. Theuniversal business card 600 shows one example of how an account holderlike the account holder discussed above may share contact informationwith other users. While a traditional business card may include severaltelephone numbers and other contact information for a number of modes ofcommunication (e.g., mail, e-mail, telephone, etc.), the universalbusiness card 600 includes a single handle that can be resolved by acentral system automatically into one of the modes of communication anda particular mechanism (e.g., telephone number) for that mode.

The universal business card 600, as shown, includes the name 602 of theaccount holder, shown as “Jodi Cisewski,” the employer 604 of theaccount holder, “Engineering, Inc.,” and a link 606 to the user'scontact identifiers using a handle 608. As shown, the handle includes atelephone number and is appended to a URL. The URL may also, inappropriate circumstances, be considered to be part of the handle 608.The URL may be a common URL that is easy for user to memorize (e.g.,because many of their acquaintances have handles associated with theURL), and the handle may also be an alphanumeric string that isrelatively easy for other users to memorize or store. The informationunderlying the universal business card 600 may be updated under theaccount holder's control to ensure that people may receive currentcontact information for the account holder, even as the data shown onthe card stays the same. The universal business card 600 also provides asmall amount of data for a third-party to receive. In this manner, athird party can see what the cardholder does, and can also be givenaccess to more information about the cardholder without having the card600 cluttered by detailed information.

FIG. 6B is a screenshot of a web page 610 for retrieving a user'scontact identifiers correlated with a handle. The web page 610 containsthe name 612 of the account holder, a handle 614, and a link 616 tocontact the account holder. In some implementations, the web page 610 isthe site connected to the link from the universal business card of FIG.6A. A person looking at page 610 may select the link 616 to be connectedautomatically to the user, where a central system may automaticallyselect the contact mechanism and mode of communication by which thecontact is to occur. For example, if Jodi currently wants to communicateby e-mail, selection of the link 616 may cause a blank e-mail messagewith a relevant e-mail address for Jodi filled out, to be generated onthe same client device that was previously displaying the page 610.

FIG. 6C is a screenshot of a web page 630 for correlating a handle withcontact identifiers. The web page 630 provides entry forms for a user toprovide contact identifiers for a system to store and correlate thecontact identifiers provided with a handle. In FIG. 6C, the fieldsinclude a handle field 632, a password field 634, and a name field 636.Other fields include phone 640, e-mail 642, IM 644, website 646, blog648, networking site 650, and VoIP 652. The fields shown below the namefield 636 each have a “+” button so that a user can add more than one ofthe types of fields display on the web page 630. For example, there maybe multiple instant messaging accounts for multiple instant messagingapplications or multiple instant messaging accounts for one instantmessaging application. If the “+” symbol is pressed, the web page 630can add another field of the same mode indicator. For example, theaddress field 638 in FIG. 6C is shown as displaying “home”. If the “+”symbol for the address field is selected, the second address field maybe marked “work” or “home2”.

In some implementations, the web page 630 provides fields for otherforms of contact, such as a call sign for an amateur radio broadcaster.In some implementations, the web page 630 may display one or more fields632-652 that include predetermined information if the system is alsoconnected to a communication mode. For example, if the user has ane-mail account that is accessible through a link displayed on the webpage 630, the web page 630 may already display the user's e-mailaddress, her home page, her user identifier and password for an instantmessaging program, her time zone, and any other information she wishesto make public to at least some of the individuals who may access herinformation through the account. In some implementations, the web page630 may have a separate page for different groups with differentsecurity levels or check boxes or pull-down menus for each field todesignate the access level for each group.

In FIG. 6C, the web page 630 also includes a column includingadvertisements 654. In some implementations, the advertisements 654 mayinclude data based on the information that the user has input to the webpage. For example, if the user provides a phone number with an area code“612”, the advertisements 654 may include data specific to Minneapolis,Minn. Similarly, the advertisements may include data that is associatedwith a website or blog, as entered in the website 646 and blog 648fields.

FIG. 6D is a screenshot of a web page 670 displaying a user's contactidentifiers correlated with a handle. The web page 670 has a contactname 672, a telephone number 674, a home e-mail address 676, a blog link678, and a contact link 680 to allow a visitor to request furthercontact identifiers. The web page 670 may be a web page for a specificgroup, such as a friends group or a family group, or the web page 670may be intended for a general group. In some implementations, the webpage 670 may also include a login area so that viewers can provide apassword to access more information.

In some implementations, the web page 670 may also display contactinformation for an account associated with a group rather than anindividual. For example, the user may be a non-profit organization witha changing executive board and contact information. In such an instance,the single point of contact may provide continuity because members orinterested parties may not need to update contact points. For example,if an executive board elects a president every year, the new presidentmay update the contact name 672, telephone number 674, and home e-mailaddress 676 upon his election. The blog link 678 may not need to bechanged, however. Likewise, if the third parties have the capability toupdate the information on an automatic basis, no time would be wastedlooking up the new contact information. It would be provided to thethird parties upon request.

The web page 670 includes a column for advertisements 682. Theadvertisements may be specified based on the user account information.The advertisements may also be sponsored. For example, the user may beprovided with a financial benefit for each visitor to the web page 670.Similarly, the user may be provided with a financial benefit each time avisitor clicks a link to one of the advertisements 682 on the web page670.

FIG. 7 is a block diagram of computing devices 700, 750 that may be usedto implement the systems and methods described in this document, aseither a client or as a server or plurality of servers. Computing device700 is intended to represent various forms of digital computers, such aslaptops, desktops, workstations, personal digital assistants, servers,blade servers, mainframes, and other appropriate computers. Computingdevice 750 is intended to represent various forms of mobile devices,such as personal digital assistants, cellular telephones, smartphones,and other similar computing devices. Additionally computing device 700or 750 can include Universal Serial Bus (USB) flash drives. The USBflash drives may store operating systems and other applications. The USBflash drives can include input/output components, such as a wirelesstransmitter or USB connector that may be inserted into a USB port ofanother computing device. The components shown here, their connectionsand relationships, and their functions, are meant to be exemplary only,and are not meant to limit implementations of the inventions describedand/or claimed in this document.

Computing device 700 includes a processor 702, memory 704, a storagedevice 706, a high-speed interface 708 connecting to memory 704 andhigh-speed expansion ports 710, and a low speed interface 712 connectingto low speed bus 714 and storage device 706. Each of the components 702,704, 706, 708, 710, and 712, are interconnected using various busses,and may be mounted on a common motherboard or in other manners asappropriate. The processor 702 can process instructions for executionwithin the computing device 700, including instructions stored in thememory 704 or on the storage device 706 to display graphical informationfor a GUI on an external input/output device, such as display 716coupled to high speed interface 708. In other implementations, multipleprocessors and/or multiple buses may be used, as appropriate, along withmultiple memories and types of memory. Also, multiple computing devices700 may be connected, with each device providing portions of thenecessary operations (e.g., as a server bank, a group of blade servers,or a multi-processor system).

The memory 704 stores information within the computing device 700. Inone implementation, the memory 704 is a volatile memory unit or units.In another implementation, the memory 704 is a non-volatile memory unitor units. The memory 704 may also be another form of computer-readablemedium, such as a magnetic or optical disk.

The storage device 706 is capable of providing mass storage for thecomputing device 700. In one implementation, the storage device 706 maybe or contain a computer-readable medium, such as a floppy disk device,a hard disk device, an optical disk device, or a tape device, a flashmemory or other similar solid state memory device, or an array ofdevices, including devices in a storage area network or otherconfigurations. A computer program product can be tangibly embodied inan information carrier. The computer program product may also containinstructions that, when executed, perform one or more methods, such asthose described above. The information carrier is a computer- ormachine-readable medium, such as the memory 704, the storage device 706,or memory on processor 702.

The high speed controller 708 manages bandwidth-intensive operations forthe computing device 700, while the low speed controller 712 manageslower bandwidth-intensive operations. Such allocation of functions isexemplary only. In one implementation, the high-speed controller 708 iscoupled to memory 704, display 716 (e.g., through a graphics processoror accelerator), and to high-speed expansion ports 710, which may acceptvarious expansion cards (not shown). In the implementation, low-speedcontroller 712 is coupled to storage device 706 and low-speed expansionport 714. The low-speed expansion port, which may include variouscommunication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet)may be coupled to one or more input/output devices, such as a keyboard,a pointing device, a scanner, or a networking device such as a switch orrouter, e.g., through a network adapter.

The computing device 700 may be implemented in a number of differentforms, as shown in the figure. For example, it may be implemented as astandard server 720, or multiple times in a group of such servers. Itmay also be implemented as part of a rack server system 724. Inaddition, it may be implemented in a personal computer such as a laptopcomputer 722. Alternatively, components from computing device 700 may becombined with other components in a mobile device (not shown), such asdevice 750. Each of such devices may contain one or more of computingdevice 700, 750, and an entire system may be made up of multiplecomputing devices 700, 750 communicating with each other.

Computing device 750 includes a processor 752, memory 764, aninput/output device such as a display 754, a communication interface766, and a transceiver 768, among other components. The device 750 mayalso be provided with a storage device, such as a microdrive or otherdevice, to provide additional storage. Each of the components 750, 752,764, 754, 766, and 768, are interconnected using various buses, andseveral of the components may be mounted on a common motherboard or inother manners as appropriate.

The processor 752 can execute instructions within the computing device750, including instructions stored in the memory 764. The processor maybe implemented as a chipset of chips that include separate and multipleanalog and digital processors. Additionally, the processor may beimplemented using any of a number of architectures. For example, theprocessor 410 may be a CISC (Complex Instruction Set Computers)processor, a RISC (Reduced Instruction Set Computer) processor, or aMISC (Minimal Instruction Set Computer) processor. The processor mayprovide, for example, for coordination of the other components of thedevice 750, such as control of user interfaces, applications run bydevice 750, and wireless communication by device 750.

Processor 752 may communicate with a user through control interface 758and display interface 756 coupled to a display 754. The display 754 maybe, for example, a TFT (Thin-Film-Transistor Liquid Crystal Display)display or an OLED (Organic Light Emitting Diode) display, or otherappropriate display technology. The display interface 756 may compriseappropriate circuitry for driving the display 754 to present graphicaland other information to a user. The control interface 758 may receivecommands from a user and convert them for submission to the processor752. In addition, an external interface 762 may be provide incommunication with processor 752, so as to enable near areacommunication of device 750 with other devices. External interface 762may provide, for example, for wired communication in someimplementations, or for wireless communication in other implementations,and multiple interfaces may also be used.

The memory 764 stores information within the computing device 750. Thememory 764 can be implemented as one or more of a computer-readablemedium or media, a volatile memory unit or units, or a non-volatilememory unit or units. Expansion memory 774 may also be provided andconnected to device 750 through expansion interface 772, which mayinclude, for example, a SIMM (Single In Line Memory Module) cardinterface. Such expansion memory 774 may provide extra storage space fordevice 750, or may also store applications or other information fordevice 750. Specifically, expansion memory 774 may include instructionsto carry out or supplement the processes described above, and mayinclude secure information also. Thus, for example, expansion memory 774may be provide as a security module for device 750, and may beprogrammed with instructions that permit secure use of device 750. Inaddition, secure applications may be provided via the SIMM cards, alongwith additional information, such as placing identifying information onthe SIMM card in a non-hackable manner.

The memory may include, for example, flash memory and/or NVRAM memory,as discussed below. In one implementation, a computer program product istangibly embodied in an information carrier. The computer programproduct contains instructions that, when executed, perform one or moremethods, such as those described above. The information carrier is acomputer- or machine-readable medium, such as the memory 764, expansionmemory 774, or memory on processor 752 that may be received, forexample, over transceiver 768 or external interface 762.

Device 750 may communicate wirelessly through communication interface766, which may include digital signal processing circuitry wherenecessary. Communication interface 766 may provide for communicationsunder various modes or protocols, such as GSM voice calls, SMS, EMS, orMMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others.Such communication may occur, for example, through radio-frequencytransceiver 768. In addition, short-range communication may occur, suchas using a Bluetooth, WiFi, or other such transceiver (not shown). Inaddition, GPS (Global Positioning System) receiver module 770 mayprovide additional navigation- and location-related wireless data todevice 750, which may be used as appropriate by applications running ondevice 750.

Device 750 may also communicate audibly using audio codec 760, which mayreceive spoken information from a user and convert it to usable digitalinformation. Audio codec 760 may likewise generate audible sound for auser, such as through a speaker, e.g., in a handset of device 750. Suchsound may include sound from voice telephone calls, may include recordedsound (e.g., voice messages, music files, etc.) and may also includesound generated by applications operating on device 750.

The computing device 750 may be implemented in a number of differentforms, as shown in the figure. For example, it may be implemented as acellular telephone 780. It may also be implemented as part of asmartphone 782, personal digital assistant, or other similar mobiledevice.

Various implementations of the systems and techniques described here canbe realized in digital electronic circuitry, integrated circuitry,specially designed ASICs (application specific integrated circuits),computer hardware, firmware, software, and/or combinations thereof.These various implementations can include implementation in one or morecomputer programs that are executable and/or interpretable on aprogrammable system including at least one programmable processor, whichmay be special or general purpose, coupled to receive data andinstructions from, and to transmit data and instructions to, a storagesystem, at least one input device, and at least one output device.

These computer programs (also known as programs, software, softwareapplications or code) include machine instructions for a programmableprocessor, and can be implemented in a high-level procedural and/orobject-oriented programming language, and/or in assembly/machinelanguage. As used herein, the terms “machine-readable medium”“computer-readable medium” refers to any computer program product,apparatus and/or device (e.g., magnetic discs, optical disks, memory,Programmable Logic Devices (PLDs)) used to provide machine instructionsand/or data to a programmable processor, including a machine-readablemedium that receives machine instructions as a machine-readable signal.The term “machine-readable signal” refers to any signal used to providemachine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniquesdescribed here can be implemented on a computer having a display device(e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor)for displaying information to the user and a keyboard and a pointingdevice (e.g., a mouse or a trackball) by which the user can provideinput to the computer. Other kinds of devices can be used to provide forinteraction with a user as well; for example, feedback provided to theuser can be any form of sensory feedback (e.g., visual feedback,auditory feedback, or tactile feedback); and input from the user can bereceived in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in acomputing system that includes a back end component (e.g., as a dataserver), or that includes a middleware component (e.g., an applicationserver), or that includes a front end component (e.g., a client computerhaving a graphical user interface or a Web browser through which a usercan interact with an implementation of the systems and techniquesdescribed here), or any combination of such back end, middleware, orfront end components. The components of the system can be interconnectedby any form or medium of digital data communication (e.g., acommunication network). Examples of communication networks include alocal area network (“LAN”), a wide area network (“WAN”), peer-to-peernetworks (having ad-hoc or static members), grid computinginfrastructures, and the Internet.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

A number of embodiments of the invention have been described.Nevertheless, it will be understood that various modifications may bemade without departing from the spirit and scope of the invention. Forexample, various forms of the flows shown above may be used, with stepsre-ordered, added, or removed. Also, although several applications ofcorrelating and retrieving a handle with contact identifiers and methodshave been described, it should be recognized that numerous otherapplications are contemplated. Accordingly, other embodiments are withinthe scope of the following claims.

1. A computer-implemented communication management method, comprising;receiving, at a computer system and submitted by a computing device, ahandle for an account holder; associating the received handle with anaccount that is identified for the account holder based on the handle,wherein the account includes multiple different contact identifiers thatare for communicating with the account holder and that correspond to aplurality of different communications modes, wherein each of thedifferent communication modes defines a form of communication that isdistinct from the other communication modes; causing to beelectronically connected, using a preferred contact identifiercorresponding to one of the plurality of different communication modes,the computing device for communication with a device associated with theaccount, the causing performed in response to a determination of thecurrent preferred contact identifier from among the multiple differentcontact identifiers as indicated by the account holder or a third partywho is using the computing device.
 2. The method of claim 1, wherein thedetermination of the current preferred contact identifier comprisesanalyzing information that identifies a preferred communication mode andthat is received with the handle.
 3. The method of claim 2, wherein thecomputing device has communication capabilities corresponding to one ofthe plurality of communication modes, and the computing deviceautomatically provides information about the communication capabilitiesto the computer system along with the handle.
 4. The method of claim 1,wherein the determination of the current preferred contact identifiercomprises analyzing a rule for making communication contact with theaccount holder that is based on a preference provided to the computersystem by the account holder.
 5. The method of claim 4, wherein thepreference specifies a particular contact identifier for one of themodes of communication, and the computer system electronically connectsthe computing device with the account holder by mapping the handle tothe particular contact identifier.
 6. The method of claim 5, wherein themodes of communication include telephone connections and electronic mailconnections, and the contact identifiers include one or more differenttelephone numbers and one or more different electronic mail addresses.7. The method of claim 1, wherein causing to be electronically connectedthe computing device for communication with the device associated withthe account is performed without providing the current preferred contactidentifier to the computing device, so that the current preferredcontact identifier stays undisclosed to a user of the computing device.8. A computer-implemented communication management method, comprising:obtaining, at a computer system, a plurality of different contactidentifiers for a computer account holder, wherein the contactidentifiers represent mechanisms for contacting the computer accountholder by a plurality of different communication modes that each definea form of communication that is distinct from the other communicationmodes; identifying a handle for the account holder, wherein the handleis associated with a uniform resource locator; and correlating thehandle with the plurality of contact identifiers, and storinginformation for carrying out a rule for selecting a current preferredcontact identifier indicated by the account holder in response toreceipt of the handle from a third party user of a communication devicethat is remote from the computer system.
 9. The method of claim 8,further comprising receiving the handle from the third party, selectinga contact identifier that is from the plurality and is associated withthe handle, and connecting the third party for communication with theaccount holder according to the selected contact identifier, using acommunication mode corresponding to the selected contact identifier. 10.The method of claim 9, further comprising identifying a mode indicatorin information received with the handle from the third party, andselecting the contact identifier after selecting the communication modecorresponding to the mode indicator.
 11. The method of claim 10, whereinthe mode indicator comprises a prefix or suffix for the handle in astring that includes the handle and is submitted by a device of thethird party.
 12. The method of claim 9, wherein selecting the contactidentifier comprises analyzing one or more contact rules established bythe account holder, and selecting the contact identifier that bestmatches the contact rules.
 13. The method of claim 9, further comprisingconnecting the third party for communication with the account holderwithout providing the selected contact identifier to the third party soas to maintain the contact identifier secret from the third party. 14.The method of claim 9, further comprising identifying a relationshipstatus of the third party relative to the account holder, andcontrolling which of the plurality of contact identifiers is used tomake the connection based on the relationship status.
 15. The method ofclaim 8, wherein the handle comprises an alphabetic name for thecomputer account holder.
 16. The method of claim 15, wherein the handlecomprises a uniform resource locator that includes a name.
 17. Themethod of claim 8, wherein the handle comprises a telephone number. 18.The method of claim 17, wherein the handle comprises a uniform resourcelocator that includes a telephone number.
 19. The method of claim 8,wherein the plurality of different communication modes comprise two ormore different modes comprising a telephone connection, an electronicmail communication, a text message, and a personal web page.
 20. Themethod of claim 8, further comprising transmitting, in response to athird party submission of the handle, information for presentation tothe third party that permits the third party to select a communicationmode, from among the plurality of different communication modes, tocommunicate with the account holder.
 21. A computer-implementedcommunication system for identifying contact identifiers for an accountholder: an interface to obtain a first and second contact identifier fora computer account holder, wherein the first contact identifier is usedto establish a verbal communication with the account holder and thesecond contact identifier is used to establish a textual communicationwith the account holder; an account manager to identify a handle for theaccount holder, wherein the handle is associated with a uniform resourcelocator; and a correlator to correlate the handle with the first andsecond contact identifiers, and to select one of the first and secondcontact identifiers, based on a preference of the account holder, forcreating a communication session between a device of the account holderand a device that submits the handle.
 22. A computer-implementedcommunication system for assisting in forming communication sessions,comprising; an interface to receive a handle from a user of a computingdevice, wherein the handle is associated with a uniform resourcelocator; a central database associating a group of contact identifiersfor an account holder to the uniform resource locator, wherein thecontact identifiers differ from each other and include contactidentifiers for a plurality of different modes of communication,including a telephone mode and an electronic mail mode; and acommunication mode selector to receive a mode indicator and one or morecontact identifiers from the database and to select a current preferredcontact identifier for the account holder for connecting a third partyfor communication with the account holder in response to a submission ofthe handle by the third party.